DCOM95 1.3 Note sulla versione Ultimo aggiornamento: 14 settembre 1998 DCOM95 fornisce il supporto Distributed COM per Microsoft(r) Windows(r) 95. Il protocollo per trasmissioni via cavo DCOM fornisce un supporto per comunicazioni affidabili, sicure ed efficienti tra i componenti COM (Component Object Model), quali i controlli ActiveX(r), gli script e le applet Java presenti su computer diversi di una rete LAN, di una rete WAN o di Internet. Con DCOM, l'applicazione può essere distribuita tra le ubicazioni più adatte al cliente e all'applicazione. Per ulteriori informazioni, fare riferimento alla documentazione tecnica su DCOM disponibile presso la home page Microsoft COM all'indirizzo http://www.microsoft.com/com/ (informazioni in lingua inglese). Sommario ======== I. Nuove caratteristiche II. Soluzioni ai problemi III. Problemi noti IV. Differenze con DCOM per Windows NT V. Ridistribuzione VI. Supporto tecnico e risorse aggiuntive VII. Elenco di file I. Nuove caratteristiche --------------- Sostituzione non consentita di DCOM95 con versioni precedenti Nelle precedenti versioni di DCOM95 era possibile sostituire una versione successiva di DCOM95 con una precedente. Ora i numeri di versione vengono verificati in fase di installazione e non è possibile installare una versione precedente su una successiva. Questa modifica consente di eliminare i problemi provocati da versioni incompatibili di DLL. Supporto per il controllo dei processi di Visual Studio 6.0 Come supporto di Visual Studio 6.0, DCOM95 fornisce agli sviluppatori informazioni sul controllo per consentire la comprensione del comportamento, della struttura e delle prestazioni delle applicazioni. Utilizzare sempre questa versione di DCOM95 se si utilizza Visual Studio Analyzer in un computer che esegue Windows 95. Creazione di una nuova directory durante l'installazione In fase di installazione, all'interno della directory di sistema viene creata una directory DCOM95 nella quale vengono memorizzati il filedel Contratto di Licenza dell'utente finale e altri file.All'interno della directory DCOM95, viene inoltre creata anche una sottodirectory OLDOLE nella quale viene conservata la copia di backup di tutti i precedenti file DCOM95 o OLE. Questi file vengono ripristinati alla disinstallazione di questa versione di DCOM95. COM Internet Services Attraverso il protocollo COM, CIS (COM Internet Services) consente la connessione di client e server su Internet. CIS comprende: * Un nuovo protocollo DCOM, Tunneled TCP * Un nuovo tipo di moniker, moniker OBJREF * Una nuova utilità CISCNFG Per il supporto client CIS in Windows 95, installare DCOM95 e DCOMCFG, quindi utilizzare l'utilità CISCNFG, installata insieme all'utilità di configurazione DCOM, per modificare la chiave del registro di configurazione che definisce il protocollo da utilizzare per i processi remoti. Nella finestra del promptdei comandi immettere: ciscnfg Dove corrisponde a: * rpc per il protocollo RPC * http per il protocollo HTTP * tcp_http per utilizzare dapprima il protocollo TCP, quindi, in presenza di un eventuale timeout del server, il protocollo HTTP. L'immissione del comando ciscnfg senza opzioni consente di visualizzare le informazioni sul relativo utilizzo. Non sono richiesti aggiornamenti SDK per il protocollo Tunneled TCP. Sono richiesti, invece, alcuni aggiornamenti per i moniker OBJREF. CreateObjrefMoniker Crea un moniker OBJREF basato su un puntatore a un oggetto. WINOLEAPI CreateObjrefMoniker( LPUNKNOWN pUnk, //Puntatore all'oggetto LPMONIKER *ppMk //Indirizzo del puntatore al moniker OBJREF ); Parametri pUnk Puntatore all'interfaccia IUnknown sull'oggetto rappresentato dal moniker. ppMk Indirizzo di un puntatore all'interfaccia IMoniker nel moniker OBJREF creato. Valori restituiti Questa funzione restituisce i valori standard E_OUTOFMEMORY e E_UNEXPECTED, oltre al seguente valore: S_OK Il valore indica che la creazione del moniker OBJREF è riuscita. Osservazioni I client utilizzano i moniker OBJREF per ottenere un puntatore su cui è stato eseguito il marshaling a un oggetto in esecuzione nello spazio di indirizzamento del server. Il server effettua in genere una chiamata a CreateObjrefMoniker per creare un moniker OBJREF, quindi effettua una chiamata almetodo IMoniker::GetDisplayName e infine rilascia il moniker. Il nome delmoniker OBJREF viene visualizzato nel formato: OBJREF:nnnnnnnn Dove nnnnnnnn rappresenta una stringa con codifica base-64 arbitrariamente lunga che racchiude l'ubicazione del computer, il termine di trasmissione del processo e l'ID del puntatore all'interfaccia (IPID) dell'oggetto in esecuzione. La stringa visualizzata può essere quindi trasferita al client in formato testo. È ad esempio possibile richiamare questa stringa in una pagina HTML scaricabile dal client. Il client può passare questa stringa a MkParseDisplayName, che a sua volta crea un moniker OBJREF. Una chiamata al metodo IMoniker::BindToObject del moniker consente di ottenere un puntatore su cui è stato eseguito il marshaling all'istanza in esecuzione sul server. Un componente COM sul lato server contenuto in una pagina ASP può ad esempio creare un moniker OBJREF, ottenerne una stringa e scrivere tale stringa in un file in formato HTML da inviare al browser del client. Uno script in esecuzione sul client può utilizzare questa stringa per accedere all'oggetto in esecuzione. Uno script Visual Basic sul lato client può ad esempio memorizzare la stringa visualizzata in una variabile denominata strMioNome e includere questa riga: oggMiaIstanza = GetObject(strMioNome) Il motore dello script effettua internamente chiamate al metodo MkParseDisplayName e IMoniker::BindToObject; a questo punto, per richiamare direttamente l'oggetto in esecuzione, lo script può utilizzare oggMiaIstanza. Se l'oggetto in esecuzione utilizza IPID statici e il processo server viene sempre eseguito sullo stesso computer in un termine di trasmissione ben definito, la stringa visualizzata del moniker OBJREF sarà sempre la stessa. In questo caso, il server può memorizzare la stringa visualizzata invece di calcolarla ogni volta che riceve una richiesta per tale oggetto. IMoniker - Implementazione del moniker OBJREF I moniker OBJREF rappresentano un riferimento a un'istanza di oggetti in esecuzione su un server out-of-process, in locale o in remoto. Il moniker identifica l'istanza di oggetti e il computer sul quale è in esecuzione l'oggetto. Per molti versi, il moniker OBJREF è simile a un moniker di puntatore, se si esclude che l'oggetto in esecuzione è out-of-process. Un client può effettuare una chiamata a IMoniker::BindToObject su un moniker OBJREF e utilizzare il puntatore che ne ottiene per accedere all'oggetto in esecuzione, indipendentemente dall'ubicazione. Una differenza importante con il moniker di puntatore è che la stringa visualizzata di un moniker OBJREF può essere richiamata in una pagina HTML e l'oggetto in esecuzione rappresentato dal moniker può essere associato da uno script, un'applet o un controllo ActiveX del client. Tempi di utilizzo Lo scopo principale di un moniker OBJREF è quello di ottenere l'accesso a un'istanza di oggetti in esecuzione su Internet. Una pagina ASP o qualsiasi altro controllo che consenta di generare un output HTML dinamico include la stringa visualizzata di un moniker OBJREF in un parametro di un'applet o di un controllo ActiveX. Il codice dell'applet o del controllo richiama il metodo CreateObjrefMoniker per creare un moniker OBJREF in base alla stringa visualizzata, quindi richiama il metodo IMoniker::BindToObject nel moniker OBJREF risultante per ottenere l'accesso all'istanza di oggetti in esecuzione. La pagina ASP esegue quindi il marshaling di un puntatore all'oggetto in esecuzione al client della pagina. Osservazioni IMoniker::BindToObject. Nel caso di moniker OBJREF, il parametro pmkToLeft deve essere NULL. Poiché il moniker OBJREF rappresenta un oggetto in esecuzione, non viene attuata nessuna attivazione. Se l'oggetto rappresentato non è più in esecuzione, BindToObject restituisce l'errore E_UNEXPECTED. IMoniker::BindToStorage. Con questo metodo si ottiene un puntatore su cui è stato eseguito il marshaling all'interfaccia richiesta sull'area di memorizzazione contenente l'oggetto in esecuzione. Poiché il moniker OBJREF rappresenta un oggetto in esecuzione, non viene attuata nessuna attivazione. Se l'oggetto rappresentato non è più in esecuzione, BindToStorage restituisce l'errore E_UNEXPECTED. IMoniker::Reduce. Questo metodo restituisce MK_S_REDUCED_TO_SELF e passa di nuovo lo stesso moniker. IMoniker::ComposeWith. Se pmkRight è un anti-moniker, il moniker restituito è NULL. Se pmkRight è a struttura mista e il primo componente da sinistra è un anti-moniker, il moniker restituito è a struttura mista e senza anti-moniker. Se pmkRight non è né un anti-moniker né un moniker a struttura mista e il primo componente da sinistra è un anti-moniker, il metodo verifica il parametro fOnlyIfNotGeneric. Se è FALSE, il metodo combina i due moniker in un moniker generico a struttura mista; se è TRUE, il metodo imposta *ppmkComposite su NULL e restituisce MK_E_NEEDGENERIC. IMoniker::Enum. Questo metodo restituisce il valore S_OK e imposta ppenumMoniker su NULL. IMoniker::IsEqual. Questo metodo restituisce il valore S_OK se *pmkOther è un moniker OBJREF e i percorsi per entrambi i moniker sono identici (verificabile con un confronto che non consideri le maiuscole e le minuscole). In caso contrario, il metodo restituisce il valore S_FALSE. IMoniker::Hash. Questo metodo calcola un valore hash per il moniker. IMoniker::IsRunning. Poiché i moniker OBJREF rappresentano un'istanza di oggetti in esecuzione, questo metodo restituisce il valore TRUE, a meno che l'oggetto non sia più in esecuzione perché non è riuscita una chiamata recente. Il metodo ignora il parametro pmkToLeft. IMoniker::GetTimeOfLastChange. Questo metodo restituisce il valore E_NOTIMPL. IMoniker::Inverse. Questo metodo restituisce un anti-moniker, ovvero il risultato di una chiamata CreateAntiMoniker. IMoniker::CommonPrefixWith. Se due moniker sono uguali, questo metodo restituisce MK_S_US e imposta *ppmkPrefix su NULL. Se uno dei due moniker non è un moniker OBJREF, il metodo passa entrambi i moniker alla funzione MonikerCommonPrefixWith. Questa funzione gestisce correttamente i casi in cui uno dei moniker è a struttura mista generica. Se non è disponibile un prefisso comune, il metodo restituisce MK_E_. IMoniker::RelativePathTo. Questo metodo restituisce il valore E_NOTIMPL. IMoniker::GetDisplayName. Questo metodo ottiene la stringa visualizzata per il moniker OBJREF. Questa è una stringa con codifica a 64 bit che racchiude l'ubicazione del computer, il termine di trasmissione del processo e l'ID del puntatore all'interfaccia (IPID) dell'oggetto in esecuzione. Per garantire una compatibilità futura, la stringa visualizzata è limitata a quei caratteri che possono essere specificati come parte di un URL. IMoniker::ParseDisplayName. Se il parametro pmkToLeft non è NULL, questo metodo restituisce MK_E_SYNTAX. IMoniker::IsSystemMoniker. Questo metodo restituisce il valore S_OK e passa di nuovo MKSYS_OBJREFMONIKER. Supporto per tipi di dati VB6.0 Visual Basic® 6.0 consente alle varianti Visual Basic di contenere strutture di dati definite dall'utente. Ora DCOM95 supporta la gestione remota di queste varianti. II. Soluzioni ai problemi ------------------------- Condizione di competizione durante lo scaricamento di più moduli Nelle precedenti versioni di DCOM95, si verificava una violazione di accesso quando venivano scaricati contemporaneamente più moduli. La violazione dipendeva dall'ordine in cui venivano scaricati i moduli. Questo errore è stato corretto in questa versione di DCOM95. Assenza di risposta del desktop durante le negoziazioni del protocollo RPC Nelle versioni precedenti di DCOM95 non venivano visualizzati messaggi durante le negoziazioni di protocolli RPC. In alcuni casi, se l'utente avviava un'applicazione mentre venivano negoziati i protocolli RPC, il computer sembrava non rispondere. Dopo 30 secondi, veniva ripresa l'elaborazione dei messaggi. Questo tipo di risposta è stato corretto nell'ultima versione di DCOM95 e le applicazioni possono essere avviate durante la negoziazione dei protocolli RPC. Assenza di risposta del desktop durante l'avvio di una nuova applicazione Il protocollo RPC crea una finestra nascosta nell'MTA (Multiple-Threaded Apartment), che non gestisce i messaggi richiesti mediante DCOM.Quando viene avviata una nuova applicazione dal desktop, Windows notifica questo evento inviando un messaggio a tutti gli altri handle di finestre e resta in attesa di una risposta. Nelle versioni precedenti di DCOM95 la finestra RPC nascosta non forniva alcuna risposta, provocando il blocco di Windows. In questa versione di DCOM95 il problema è stato risolto e la finestra RPC non blocca più il desktop quando vengono avviate nuove applicazioni. Danneggiamento dell'heap in presenza di più indirizzi IP In alcune situazioni se veniva avviata una versione precedente di DCOM95 su un computer con più di un indirizzo IP, il buffer degli indirizzi IP risultava sovraccaricato, provocando il danneggiamento dell'heap. Questo problema è stato risolto nell'ultima versione di DCOM95. Utilizzo del primo indirizzo IP utile Se si avviava una versione precedente di DCOM95 su un computer dotato di due schede di rete e quindi di due indirizzi IP, ciascuno assegnato a una scheda diversa, DCOM95 utilizzava soltanto una scheda di rete. In questa versione di DCOM95, se il primo indirizzo non è adatto, viene utilizzato il secondo. Utilizzo di più indirizzi IP con RPC Nell'esecuzione di una chiamata di procedura remota (RPC, Remote Procedure Call) a un computer con più indirizzi IP, verranno provati altri indirizzi IP se la connessione con il primo non riesce. Sintassi di percorso aggiuntiva supportata dai moniker di file I moniker di file ora possono essere creati senza considerare il formato , ad esempio "C:\bug\bug\..\..\foo.jpg". In DCOM95 1.1 erano consentiti soltanto percorsi relativi, ad esempio "..\..\foo.jpg", o assoluti, "C:\foo.jpg". Errore di protezione generale durante lo scaricamento della libreria Oleaut32.dll Nelle versioni precedenti di DCOM95 si verificava un errore di protezione generale quando veniva scaricata la libreria Oleaut32.dll prima di una chiamata a CoUninitialize. Questa situazione si verificava molto spesso quando un'applicazione VB creava un controllo collegato in modo statico alla libreria Oleaut32.dll, quindi lo rilasciava prima di effettuare la chiamata a CoUninitialize. Questo errore di protezione generale è stato risolto nell'ultima versione di DCOM95. Marshaling e unmarshaling di tipi in Visual Basic È stato risolto il problema del marshaling e dell'unmarshaling di alcuni tipi di dati Visual Basic. Ora è possibile utilizzare parametri di matrice di dimensioni superiori ai 64 KB. Delle strutture definite mediante alias del tipo viene ora effettuato correttamente il marshaling e l'unmarshaling. Troppe eliminazioni di atomi in OleUninitialize Questo problema era stato evidenziato nelle applicazioni che chiamano OleInitialize e OleUninitialize più volte. Durante l'inizializzazione, OLE aggiunge numerosi atomi per l'RPC DDE. Se sono già stati aggiunti atomi da un altro thread, non ne vengono aggiunti altri. Tuttavia, durante la fase di fine inizializzazione, gli atomi vengono sempre eliminati e gli handle non vengono annullati. Di conseguenza, nel momento in cui veniva effettuata una nuova chiamata a OleInitialize, gli handle precedenti continuavano a essere presenti sebbene gli atomi fossero stati già eliminati e non fosse previsto di aggiungernealtri da OLE. Tutti gli atomi OLE venivano invalidati dopo numerose chiamate a OleInitialize e OleUninitialize. Il problema è stato risolto in questa versione di DCOM95. Arresto corretto dei server ADO Active Data Objects (ADO) utilizza i moniker di puntatore per avviare un processo server. Le versioni precedenti di DCOM95 presentavano un problema relativo al numero di riferimenti del moniker di puntatore, per i quali venivano creati moniker di puntatore con un numero di riferimento iniziale di 1 invece di 0. Di conseguenza, il numero di riferimento del moniker di puntatore non veniva mai riportato a zero e il moniker non veniva rilasciato, rendendo impossibile l'arresto dei server ADO anche dopo il rilascio dell'ultimo puntatore. Il problema è stato risolto in questa versione di DCOM95. Funzionamento di CoCreateInstance con un proprio nome DNS Nelle versioni precedenti di DCOM95 la chiamata a CoCreateInstance con il nome assoluto del computer locale non aveva esito positivo. Questo problema è stato risolto nella versione corrente di DCOM95 e ora CoCreateInstance crea un'istanza sul computer locale. Commit lento sull'area di memorizzazione principale per file composti molto ampi Nelle versioni precedenti di DCOM95 il commit sull'area di memorizzazione principale aperto nella modalità STGM_TRANSACTED rallentava enormemente al crescere dei file composti, ad esempio 400 MB. I limiti della tabella di pagina interna sono stati aumentati e questo non costituisce più un problema. Esportazione di oggetti da un MTA ricreato Nelle versioni precedenti di DCOM95 un server non era in grado di esportare un oggetto da un MTA (Multi-Threaded Apartment) se questo veniva creato per la prima volta nel processo. Questo problema è stato risolto. Se ora un server crea un MTA, lo distrugge e subito dopo ne crea uno nuovo; in questo modo, è possibile esportare oggetti dall'MTA. Istanze multiple di eseguibili di Visual Basic 4 In DCOM95 versione 1.1 se venivano avviate più istanze dello stesso eseguibile di Visual Basic 4, quindi venivano chiuse in un ordine diverso da quello indicato dal metodo LIFO (Last-In First-Out), l'ultimo exe veniva bloccato. Una situazione analoga si verificava con i moduli di posta elettronica di Microsoft Exchange. Questo problema è stato risolto nell'ultima versione di DCOM95. Adesso è possibile chiudere gli exe di Visual Basic 4 in qualsiasi ordine. Caratteri estesi in nomi file di Visual Basic Se a un modulo o a una classe Visual Basic venivano assegnati nomi con caratteri estesi di una determinata lingua, il file corrispondente poteva non essere aperto sui computer configurati con impostazioni locali diverse. Questo problema è stato risolto. III. Problemi noti ----------------- Corel WordPerfect Suite 7: errore di pagina non valida durante l'installazione Se si installa Corel WordPerfect Suite 7 in un sistema Windows 95 con DCOM95 in esecuzione, è possibile che si verifichi un errore di pagina non valida in PfOd70.pfc durante l'installazione. Se si verifica questo errore, chiudere la corrispondente finestra di messaggio. L'installazione dovrebbe continuare regolarmente. Microsoft Access95: mancata esecuzione della replica dei database Se si prova a replicare un database Access mediante Microsoft Access 95 su computer sui quali è installato DCOM95, è possibile che venga visualizzato il seguente messaggio di errore: Impossibile trovare o inizializzare la DLL Msjtrclr. Operazione non completata. Questo è un problema di Microsoft Access 95. È possibile ovviarlo scrivendo un programma che utilizzi il modello di oggetti di Access invece dello strumento di replica oppure utilizzando Sincronia file per la replica. Questo problema non si verifica in Microsoft Access 97. WordPerfect Se in un documento WordPerfect viene richiamato un foglio di calcolo di Corel e tale foglio a sua volta richiama un altro oggetto, ad esempio una bitmap, è possibile che venga visualizzato un messaggio di avviso in cui si notifica che viene persa la connessione alla rete se si chiude l'oggetto più interno. Possono essere visualizzati fino a quattro o cinque messaggi simili. Tutti questi avvisi non costituiscono un problema. È sufficiente chiudere le relative finestre e continuare. I client MTA che utilizzano le routine di conversione BSTR possono bloccare i messaggi DDE Le routine di conversione BSTR per l'automazione, ad esempio BstrFromR4, creano finestre nascoste per facilitare la conversione dei tipi. Queste finestre non gestiscono la coda di messaggi di Windows. Se viene creata una di queste finestre in un client MTA, è possibile che vengano bloccati i messaggi DDE. Secondo il modello di programmazione MTA, il thread del client non deve necessariamente gestire la coda di messaggi. In caso contrario, questa finestra di livello superiore provoca il blocco della trasmissione globale dei messaggi. Questa situazione può essere risolta in due modi: chiamando le routine di conversione BSTR da un client STA (Single-Threaded Apartment) oppure adeguando l'MTA del client a thread STA. Un thread STA deve necessariamente gestire la coda di messaggi. Se il thread viene bloccato in un handle win32, deve chiamare la funzione MsgWaitForMultipleObjects per distribuire contemporaneamente i messaggi di Windows. I nomi di percorso delle DLL più lunghi di 127 caratteri provocano degli errori Se si registra una DLL con un nome di percorso di 128 caratteri o superiore,la registrazione avrà esito positivo, ma CoCreateInstance o CoGetClassObjectrestituiranno un errore (REGDB_E_CLASSNOTREG) quando si accede a un oggetto supportato da tale DLL. IV. Differenze con DCOM per Windows NT --------------------------------------- Funzioni di protezione di DCOM95 La funzionalità di base e l'interfaccia per la programmazione di applicazioni (API) di DCOM95 sono identiche sia in Windows 95 sia in Windows NT 4.0/5.0. Alcune funzioni relative alla protezione sono tuttavia diverse a causa delle diverse infrastrutture di protezione dei sistemi operativi. Si consiglia di utilizzare le impostazioni di protezione predefinite del sistema in uso, inoltre è necessario attivare la protezione "a livello utente" nel caso di condivisione del file system. Per ulteriori informazioni, fare riferimento a quanto illustrato di seguito. I servizi che seguono possono essere utilizzati in sostituzione delle impostazioni di protezione predefinite: * CoInitializeSecurity * CoQueryAuthenticationService * CoQueryProxyBlanket * CoSetProxyBlanket * CoQueryClientBlanket * Interfaccia IClientSecurity * Interfaccia IServerSecurity Tuttavia, alcune funzioni di DCOM per Windows NT non sono disponibili in Windows 95 a causa di differenze nell'infrastruttura di protezione di Windows 95. In particolare, è da tenere in considerazione la mancanza di funzioni di protezione nell'API Win32, ad esempio la possibilità di creare file ACL (Access Control List, Elenco di controllo di accesso), e della funzione AccessCheck, così come la mancanza di un contesto di sicurezzaassociato ai token di thread e di processo. Windows 95 di per sé non supporta queste funzioni o costrutti. Per questo motivo, DCOM95 non supporta la rappresentazione (in modo specifico, le funzioni di guida CoImpersonateClient e CoRevertToSelf nell'interfaccia IServerSecurity), che si basa sulla protezione a livello di token di thread e di processo in Windows NT 4.0. La rappresentazione viene comunemente utilizzata per controllare automaticamente l'accesso a risorse di sistema limitate, ad esempio il file system, la rete e altri processi. Queste risorse non sono limitate in Windows 95. DCOM95, tuttavia, offre ai programmatori diversi oggetti di guida che consentono una funzionalità ACL e un controllo dell'accesso, che possono essere utilizzati per controllare in modo esplicito l'accesso di client remoti alle risorse di sistema, alle risorse definite dall'utente o ai dati. Questi oggetti guida vengono forniti dall'oggetto di sistema CLSID_DCOMAccessControl, che implementa l'interfaccia IAccessControl. IAccessControl va utilizzato per gestire le autorizzazioni relative alla protezione in modo programmatico, quando si gestisce la portabilità tra Windows 95/98 e Windows NT. L'oggetto CLSID_DCOMAccessControl è disponibile in tutte le versioni di DCOM95 e in Windows NT 4.0 con Service Pack 2 o versione successiva. Per ulteriori informazioni sull'oggetto IAccessControl, fare riferimento alla documentazione relativa all'SDK della piattaforma. Protezione dell'avvio e dell'accesso In DCOM95 non è possibile controllare l'avvio di codice della classeserver, perché non è supportata la funzione di avvio dei server. Per poter connettere i client remoti a server o a classi e consentire loro di poterli utilizzare, è necessario che i server e le classi siano già attivi. DCOM95 supporta la capacità di connettersi a classi e server già in esecuzione. La protezione dell'accesso è supportata mediante la chiave del registro di configurazione \APPID\{.}\AccessPermissions ed è regolata mediante l'utilità DCOMCNFG o in fase di installazione del codice server. Gli utenti non autenticati potranno utilizzare i server se la classe viene configurata per supportare connessioni senza autenticazione (attraverso strumenti di configurazione statici oppure dinamicamente attraverso la funzione CoInitializeSecurity). È possibile creare elenchi di controllo di accesso arbitrari per definire gli utenti e i gruppi che possono accedere a determinati servizi. Livelli di autenticazione I client DCOM95 possono effettuare chiamate DCOM utilizzando qualsiasi livello di autenticazione. I server o i client DCOM95 che ricevono callback possono accettare chiamate DCOM soltanto utilizzando i livelli di autenticazione RPC_C_AUTHN_LEVEL_NONE o RPC_C_AUTHN_LEVEL_CONNECT. Trasmissioni DCOM95 supporta soltanto connessioni di tipo TCP. Se non è installato il protocollo TCP/IP, DCOM95 non sarà in grado di supportare il COM tra macchine. Impostazioni del registro di configurazione DCOM95 stabilisce le seguenti chiavi del registro di configurazione in HKEY_LOCAL_MACHINE\Software\Microsoft\OLE: EnableDCOM (valore predefinito = "Y"). Abilita DCOM sul computer in uso. Se impostato su "N", il computer non può effettuare la connessione o attivare oggetti su computer remoti e questi ultimi non possono connettersi a oggetti presenti sul computer locale. L'impostazione di questo valore su "Y" consente la connessione come client a oggetti remoti (come nel caso di EnableRemoteConnect='N', riportato di seguito) o una connessione completa client/server (come nel caso di EnableRemoteConnect='Y', riportato di seguito). EnableRemoteConnect (valore predefinito = "N"). Abilita i server COM per il supporto dei client remoti. Se impostato su "Y", questo valore consente di passare i riferimenti alle interfacce su oggetti locali a client remoti e di connettere i client remoti a oggetti in esecuzione. Se il valore viene impostato su "N", il computer può connettersi agli oggetti remoti ma non può agire da server: infatti, al computer non viene concessa la possibilità di connettersi a oggetti in esecuzione. Inoltre, viene definita la seguente chiave del registro di configurazione in HKEY_CLASSES_ROOT\CLSID: {bdc67890-4fc0-11d0-a805-00aa006d2ea4}\InstalledVersion. Contiene il numero di versione di DCOM95 nel formato "a,b,c,d". Questo valore può essere utilizzato da Internet Component Download per stabilire se DCOM95 è installato. Questo valore viene aggiunto al registro di configurazionedurante l'installazione e non deve essere modificato. Utilizzo di Windows 95 come host server remoto Windows 95 può essere considerato un host server remoto, con le seguenti eccezioni: * Non è in grado di avviare le applicazioni. Perché un client possa connettersi, il processo server deve essere già in esecuzione. * Se sono richieste connessioni protette, il server (e in caso di callback, il client) deve disporre di un controllo dell'accesso a livello utente attraverso il nome del provider di protezione impostato. * Il valore del registro di configurazione "EnableRemoteConnect" deve essere impostato su "Y". Tutti i test funzionali condotti su DCOM95 sono stati effettuati utilizzando un provider della protezione di dominio di Windows NT. È possibile che si verifichino dei problemi se si utilizzano altri provider di protezione. Per stabilire un controllo dell'accesso a livello utente, è necessario che sia installato il file Filesec.vxd. In genere, questo file viene installato nei computer che eseguono Windows 95 quando si installa il servizio di condivisione file e stampa. Per abilitare il controllo dell'accesso a livello utente, fare doppio clic sull'icona Rete nel Pannello di controllo, scegliere la scheda Controllo di accesso, selezionare l'opzione Controllo di accesso a livello utente e immettere il nome del dominio di protezione. Questa operazione può influire sulla modalità di condivisione delle directory in rete dal proprio computer; per ulteriori informazioni, vedere la documentazione in linea. Se non viene visualizzata la scheda Controllo di accesso nel pannello di configurazione della rete, è necessario installare un servizio client di rete. Fare clic sul client di rete, specificando nell'indice della Guida in linea la voce relativa all'installazione di un client di rete. V. Ridistribuzione ----------------- Per informazioni sulla ridistribuzione di DCOM95, leggere attentamente le indicazioni contenute nel Contratto di Licenza con l'utente finale (license.txt). VI. Supporto tecnico e risorse aggiuntive ----------------------- Servizio Supporto Tecnico Clienti Per qualsiasi domanda riguardante un prodotto Microsoft: Consultare la documentazione ed altro materiale stampato incluso nella confezione del prodotto. Consultare la Guida in linea. Consultare i file LEGGIMI presenti nei dischi del prodotto. Questi file contengono informazioni generali divenute disponibili dopo la stampa dei manuali. Consultare le informazioni tecniche disponibili su Internet all’indirizzo http://www.microsoft.com/italy/support/ Se non si trova una soluzione, è possibile ricevere informazioni su come ottenere assistenza per i prodotti contattando la filiale Microsoft del proprio paese. Servizi di supporto Microsoft I servizi di supporto Microsoft, ove disponibili, offrono un’ampia gamma di scelte e accesso ad un supporto tecnico completo e di alta qualità. Microsoft riconosce che le esigenze di supporto variano da utente a utente, per questo Microsoft consente di scegliere l’assistenza più adatta alle proprie esigenze, con opzioni che vanno dai servizi accessibili via Internet a programmi di assistenza annuale. I servizi di supporto Microsoft sono soggetti ai prezzi, termini e condizioni Microsoft validi in ogni paese al momento in cui un servizio viene usato e sono soggetti a cambiamenti senza preavviso. Chiamare la filiale Microsoft Prima di chiamare, accertarsi di avere a portata di mano la documentazione del prodotto e di trovarsi in prossimità del computer. Potrebbe inoltre essere necessario fornire le seguenti informazioni: Il numero di versione del prodotto Microsoft utilizzato e il numero di serie, se disponibile. Il tipo di hardware di cui si dispone, compreso l’hardware di rete, se esistente. Il sistema operativo in uso. Il contenuto esatto dei messaggi visualizzati. La descrizione dell’operazione che si stava eseguendo quando si è verificato il problema. Il modo in cui si è tentato di risolvere il problema. Microsoft fornisce un servizio gratuito di assistenza tecnica telefonica, riservato agli utenti registrati per un periodo limitato, su tutte le problematiche di installazione e sulle funzionalità di più frequente utilizzo. Chi acquista un prodotto Microsoft può avvalersi di tale servizio telefonando al numero 02 - 70 398 398. Informazioni relative ad altre forme di supporto tecnico si ottengono telefonando al Servizio Clienti che risponde allo stesso numero. Per l’Italia: Microsoft Centro Direzionale S. Felice Palazzo A Via Rivoltana, 13 20090 Segrate MI Telefono: 02 - 703921 Fax: 02 - 70392020 Servizio Clienti Microsoft: 02 - 70398398 Indirizzo Internet: http://www.microsoft.com/italy/ Supporto tecnico gratuito I newsgroup rappresentano una grande opportunità per ottenere supporto gratuito qualificato. Se il tempo e le risorse lo consentono, gli sviluppatori, i responsabili di programmi, i tecnici del supporto e dei laboratori di test di Microsoft raccolgono le domande rivolte al sito e rispondono alle questioni oppure forniscono informazioni dettagliate. Non è assolutamente garantita una risposta da Microsoft alle domande formulatenei newsgroup. Per rivolgere domande su DCOM95, è possibile utilizzare i seguenti newsgroup: * comp.os.ms-windows.programmer.ole * microsoft.public.win32.programmer.ole La lista di distribuzione DCOM rappresenta un'altra buona opportunità per ottenere supporto gratuito. Il vantaggio di una lista di distribuzione è che attraverso questa lista Microsoft fornisce in anteprima le informazioni relative a un determinato argomento. Anche in questo caso si tratta di un supporto qualificato e sebbene la lista sia monitorata con continuità dallo staff Microsoft, non è assolutamente garantita una risposta alle domande formulate. Per ulteriori informazioni sulla lista di distribuzione DCOM, visitare il sito Web corrispondente all'indirizzo: http://www.microsoft.com/sitebuilder/resource/mail.asp Invio di commenti e suggerimenti Inviare qualsiasi commento o informazione sui problemi riscontrati alla lista di distribuzione DCOM. Risorse aggiuntive Ulteriori informazioni su DCOM sono disponibili presso la home page DCOM all'indirizzo http://www.microsoft.com/com/ (informazioni in lingua inglese) VII. Elenco di file -------------------- In questa tabella sono elencati i numeri di versione dei file distribuiti con DCOM95. oleaut32.dll 2.40.4273 secur32.dll 4.10.1999 compobj.dll 2.3.2 ole2.dll 2.3.2 ole32.dll 4.71.2900 olecnv32.dll 4.71.2900 olethk32.dll 4.71.2900 rpcltc1.dll 4.71.2900 rpcltc5.dll 4.71.2900 rpcltccm.dll 4.71.2900 rpclts5.dll 4.71.2900 rpcltscm.dll 4.71.2900 rpcns4.dll 4.71.2900 rpcrt4.dll 4.71.2900 rpcss.exe 4.71.2900 storage.dll 2.3.2 stdole2.tlb 2.40.4273 stdole32.tlb 2.1 imagehlp.dll 4.00 dllhost.exe 4.71.2900 comcat.dll 5.0 iprop.dll 4.00 rpcmqcl.dll 4.71.2900 rpcmqsvr.dll 4.71.2900 olepro32.dll 5.0.4273 asycfilt.dll 2.40.4273 dcom2w98.dll 2.10.35.35 In questa tabella sono elencati i numeri di versione dei file distribuiti con DCM95CFG. dcomcnfg.exe 5.00.1603.0 ciscnfg.exe 4.71.2618